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Abstract 


KATE is a model-based software system developed in the ^ftiftdal ime.ligence 

Laboratory at the Kennedy Space Center or order to brine KATE to the level 

of launch vehicles and ground support sys em • ^ ^ firin g room applications, 

KATE in the C ++ programming language using 

an X-windows interface. 

This report describes two programs ^luchha^eteen ^^^^caUed the 

collection of tools which capabi nty to view digitized schematic 
schematic viewer, gives the d tool called the model editor, gives 

btuseful Anyone maintaining or extending either the schemata 
viewer or the model editor. 


469 



Summary 


The Knowledge-based Autonomous Test Engineer (KATE) system is a model- 
based software system which has been developed in the Artificial Intelligence 
Laboratory at the Kennedy Space Center over the last decade. It is designed for 
monitoring, fault detection, and control of launch vehicles and ground support systems. 
In order to bring KATE to the level of performance, functionality, and integratability 
needed for firing room applications, efforts are currently under way to implement 
KATE in the C++ programming language using an X-windows interface. The version 
of KATE currently under development is called KATE-C; however, we will omit this 
distinction and refer to KATE generically. 

This report commences with a brief introduction to the fundamental principles 
behind the operation of KATE. Emphasis is placed on the structure and importance 
of KATE's knowledge-base. We then describe two programs which have been 
designed and added to the collection of tools comprising what is called the KATE 
toolbox. The first tool, called the schematic viewer, gives the KATE user the capability 
to view digitized schematic drawings in the KATE environment. This tool was 
designed to illustrate the potential for integrating real-life schematics into the operation 
of KATE. The second tool, called the model editor, gives the KATE model builder a 
tool for creating and editing knowledge base files. Without such a tool the KATE 
model builder has to create and edit knowledge bases outside of the KATE 
environment using a traditional text editor. The body of this report discusses design 
and implementation issues having to do with these two software tools which have been 
designed and prototyped this summer. It will be useful to anyone maintaining or 
extending either the schematic viewer or the model editor. 
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AN 


introduction to model-based reasoning 


1 1 BASIC PRINCIPLES 
The premise of mode, -based 

model of a physical system 1S erconnec tions. The physical system, which must 

components of the system an nn pration As the physical system operates, sensor 

have numerous sensors, is put into nTodel. As long 

readings are compared to their predicted va d icted values and actual sensor 

as there are no significant d ^P a ^ - ^ ant discrepancy occurs, the model-based 
readings, nothing is done. When S necessary to alert a human that a 

“ g is simply known as 

monitoring. 

If model-based reasoning systems Knowledge- 

limited utility. Fortunately, model ' b ^pf have other powerful capabilities. Among 
based Autonomous Test Engineer a sig nificant discrepancy has been 

the most interesting is ai ure ^ jg utilizes its internal representation of the 
identified in the monitoring stage, JMX ubhx to the conflict 

physical system in an effort to l Snificant difference between 

between predicted values and actua is KATE's ability to 
this reasoning process and tradition p A high-level overview of the 

IS illustrated In Hg ura M. 

In addition to their ability j t ° other very useful 

Tauter hasthe ^^1^ 
it Should be possible to descr.be a that state. If the 

reasoning system .determine wh »l nd ompone nts, as is frequently the case in 

physical system has redundant pathw y determine how to continue operahon 

NASA systems, the model-based system components have failed. It is also 

of the physical system after system construct an explanation of the 

^^s^tak^^idemify r^aUed^c^rn^nent o/Jachieve a specific objective. 

addition to their operational use 

potential as training tools. An |^ str ^ ° r ability to respond to almost any failure in 

use for model-based reasoning systems is to 
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determine the adequacy of the sensors in a complex system before it is built. For a 
more in-depth introduction to model-based reasoning see [1]. 



Figure 1-1. Overview of Model-based Reasoning 


1.2 KNOWLEDGE-BASES 


In order for a model-based reasoning system to function, it must have information 
about the structure and operation of the physical system to be modeled. We call such 
information about the real world the system's knowledge-base. As characterized in 12J 
for the KATE system: 


The KATE knowledge base contains vital information about the physical 
system that KATE is controlling or monitoring. This information is the raw 
material used by KATE to construct a simulation model that mimics the 
system's structure and function. Objects in the model have a one-to-one 
correspondence with parameters, commands, sensors, and other components 
in the physical system. The knowledge-base is referenced by KATE in the 
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same way that schematic diagrams and operating specifications are used by 
system engineers. 

121 THE KATE KNOWLEDGE-BASE. In order to lay the 
discussed later in this report, we elaborate upon the organization of K 
knowledge-base— a three-level hierarchical structure. Such hierarchical structures are 
“d^altion of knowledge-bases used for model-based reasoning 

systems. 

i 9 ii Hittii level system knowledge. The so-called "top-level of KATE s knowledge 

base represents information abouf^y broad classes of system components. For the 
base represents imor currently used, these classes are commands, 

measurements, components, pseudo objects, display function designators and so called 

systenOcomponent classes requires possible extensive mod.f.cations to the source co e. 
Fortunately, such changes occur infrequently. 

1212 Midd le level system knowledge. The so-called "mid-level" of KATE'S 

knowledge-base represents information about specific types of system com P°" en ‘ S , 

i fViic rlac<; rontains knowledge about components such as pumps, relays, 

has a regular, predictable, organization and syntax which makes it easy to add . 

inherits knowledge from its parent class. 

The flatfiles representing low-level knowledge * re 

defined keyword-based syntax. They are read by KATE at run time in o 
construct an internal representation of the physical system to e mo 
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II 


THE SOFTWARE ENVIRONMENT 

2.1 PROGRAMMING LANGUAGE AND GRAPHICS INTERFACE 

Several implementations of the general principles underlying KATE have been carried 
out over the past decade under various titles, for example, the LOX [3] and ECS[2] 
systems. These systems were originally developed in LISP— the traditional language for 
rapid prototyping of AI systems— as a proof of concept. 

In order to bring KATE to the level of performance and functionality needed for firing 
room applications, current efforts focus on simultaneously porting KATE to the C++ 
programming language while advancing its capabilities. C++ is an object-oriented 
language developed at Bell Laboratories. It is a derivative of the C programming 
language with features which encourage the writing of modular, reusable code. The 
work described in this report required the investigator to achieve proficiency in the 
C++ programming language. 

For a software system as complex as KATE to be accepted and used by firing room 
personnel it must have an excellent user interface. At the same time, the KATE 
environment must be accessible from several different hardware platforms. In order 
to achieve both of these goals, the user interface for all KATE modules currently under 
development must adhere to the Motif/ X-Windows graphics user interface standards. 
As with C++, it was necessary for the investigator to develop proficiency with these 
tools in order to carry out the work described herein. 

2.2 FRAME UTILITIES 

In an effort to standardize the user interface of KATE, user interface components are 
implemented as so-called "frame utilities". A frame utility interacts with the main body 
of KATE in a specific way and inherits graphic and functional properties from the 
KATE user interface environment. Working with frame utilities provides conveniences 
for the implementor but, at the same time, places constraints on the appearance and 
operation of the code being developed. 
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THE SCHEMATIC VIEWER FRAME UTILITY 

3.1 REQUIREMENTS 

The first KATE utility developed this summer is known as the Schematic Viewer Frame 
Utility (SVFU). The goal was to add to the set of tools available 
envirlment a way for the KATE user to view schematic drawings. Specific 

requirements for this program were: 

o The SVFU must operate as a frame utility. ... 

o The SVFU should allow a KATE user to view digitized schematic drawings 

within the KATE environment. . 

o The SVFU should allow a KATE user to view system overview drawings 

created using a "painting" program. , . 

o The SVFU should be useful for demonstrating the potential for accessing 

digitized information within the KATE environment. tCATF 

o The SVFU should be designed and implemented in such a way that KATE 

model and hardware values can be superimposed on the drawings while 

KATE is executing. 

3.2 ACHIEVEMENTS 

A frame utility was developed which met the requirements listed above. Figure 2-1 
^ow^Ae appearance of the SVFU within the KATE user interface. In this example 
a schematic drawing was digitized and loaded into the SVFU. Any image file in either 
th^X-wi^dows ^bitmap (.xbm) or X-windows pixmap (.xpm) format can be loaded and 
viewed. Using the Portable Pixmap library from MIT, almost every graphics and 
imaee file format can be converted to a bitmap or pixmap which can then be viewe 
in KATE. The SVFU allows the user to load multiple image files and t ^ 
among them quickly and easily. The utility has been demom !^ 
users and has been well received. There has been discussion of the . 

having digitized schematic drawings stored on compact disc for loading into the SVFU. 


3.3 ENHANCEMENTS 

Work has begun on superimposing KATE values on top of drawings in the SVFU. 
This should be a very useful tool for console operators using KATE. 


477 



Figure 3-1. The Schematic Viewer within the Kate User Interface 

Loading large files into the SVFU is time consuming. The files loaded into the SVFU 
need to be in a compressed format. This would greatly reduce the storage space 
required for storing large collections of digitized schematics and would improve the 
time to load a schematic into the system. This modification will require the SVFU to 
read image files stored in at least one widely used compression format. The ability to 
read various image file formats, compressed and uncompressed, would be ideal. 

The initial version of the SVFU does not support the quick-loading feature expected of 
a frame utility. Several menu buttons for such things as "Help” options are not 
functional. The program has not been thoroughly checked for potential memory leaks. 
These are all issues which can be resolved quickly. 
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IV 


the model editor 


o 

o 


o 

O 


4.1 MOTIVATION 

Constructing a KATE knowicdge-ba* 

ramp^en^^^tnudc^Euilder proceeds along the Mowing lines-. 

Gather together schematics and engineering documents for the phystcal 

Stodythe mrg^ttysteln to gain an understanding of its principal components 
and their interactions. i H middle level component classes are 

SS" «S“ IK PW“ 

measurements in the physical s y st ^V compone nts in the flatfile. 

^ cal “ of groups 

components in the system. 

There are currently no tools to vtw the model under 

a text editor and there is no w y files inve stigator undertook to desig 

anTunp^emen^wpWsticate^, graphically oriented tools to assist in t e process 

constructing KATE knowledge-bases. 

4.2 DESIGN 

With the benefit of preliimnary^M^mdocumen^ 

^iuXJSin nZ 4-1. ^ pnncipaHeamre level 

environments, one for the f,atl ® evc h portions of an editing environment 

components. Henceforth we shall refer to ^ those p^ ^ ^ ^ flatfile edltor (FFE) 

which have to do with editing " . ditin „ the middle level components as the 

and to those portions wh.ch perl t ^ j§E obla ins a description of the middle 
middle level editor (MLE). In Figu ronta ining enough information about each 

level of a knowledge base by reading a file gaming e ^ to be edited 

middle level component to allow ' * f editing and updating not only this middle 
intelligently. The MLE » and code files, 

level description file but also the mia level 
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Figure 4-1. Preliminary Design for a Model Editing Environment 

Upon further study it was decided that it might be possible to eliminate the additional 
file of meta-level descriptions of the middle level components by gleaning the required 
information directly from the mid-level header (.hpp) files. This revised design, 
illustrated in Figure 4-2, was pursued for the remainder of the project. 

4.3 REQUIREMENTS 

4 31 THE FLATFILE EDITOR. With the assistance of existing design documents and 
with an overall design plan in hand, specific requirements for the FFE portion of the 
model editor were developed. They are: 

o The flatfile editor should be a frame utility. In the short term this 
requirement is not critical. However, there are two compelling reasons for 
having the flatfile editor tightly integrated into the KATE user interface. 
First, the simulation capability of KATE could be used to assist in the 
verification of a model while still under development. This could greatly 
enhance the ability of the model builder to create a thorough, accurate model 
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Figure 4-2. Revised Design for the Model Editor 
middle level of the knowledge • X middle level header file 

• SHiasr 

" we are makinf a slightly more specific reqmrement here. 

4.3.2 THE MIDDLE LEVEL .EMTORThe only specific 

level editor is that it shou d e 1 , Given the software organization of 

for Ms editor to be a tightly integrated part of the 


481 


















KATE environment. Any change to the middle level of the knowledge base requires 
the entire KATE system to be recompiled and linked. At this time no further work has 
been done on this portion of the editing environment. The remainder of this report 
deals exclusively with the flatfile editor. 

4.4 IMPLEMENTATION OF THE FLATFILE EDITOR 

A significant portion of the flatfile editor has been implemented. The following 
discussion will describe the major components of that program at a level which would 
be useful to someone endeavoring to continue development of this software. 

4.4.1 OVERVIEW. At the highest level, the FFE works as a frame utility. The 
principal C++ class used is called the FFEFrameUtilityClass. Instances of this class 
manage three principal subdivisions of the screen along with a list of structures related 
to the individual files loaded into the editor at any point in time. 

The FFE's portion of the screen is subdivided into a menu bar, a list area and a 
drawing area. The menu bar is used to select editing commands and options for the 
editor. The list area is used to list the names of the objects in the flatfile currently 
being edited. Several options have been proposed for restricting and organizing the 
content of this list window. The drawing area can currently only be used to display 
a tree-like representation of the flatfile being edited. This drawing area conceivably 
could be used to display an icon-based representation of the flatfile being edited. 

The FFEFrameUtilityClass also maintains a list called the FlatFileList. Each item on this 
list is itself an instance of a C++ class containing information specific to a single flatfile. 
Along with obvious entries such as the name of the flatfile, each instance contains 
several entries including a list of the objects in the flatfile and a flag indicating whether 
or not any editing changes have been made since the file was saved to disk. 

Two other important classes of objects are the TopLevelClass and the MidLevelClass 
objects. The TopLevelClass represents useful information about the editing of top-level 
KATE classes. The MidLevelClass represents similar information for each mid-level 
component class. For example, the MidLevelClass instance for a Pump would contain, 
among many other items, the names of the input values expected for a Pump. The 
information for the MidLevelClass is gathered almost exclusively at run time by 
scanning through a mid-level header file. Interestingly enough, the C code to carry out 
this scanning is generated by the UNIX tool lex. If the syntax of the middle level 
KATE classes changes, the code which scans the mid-level header file can be modified 
by making simple changes to the lex file describing the structure of header files. 

4.4.2 OPERATION. When the FFE is loaded, a pane is obtained within the KATE 
runtime user interface. At this point the user has two choices— load an existing flatfile 


for editing or create a new flatfile from scratch, if the user chooses to load an existing 
file the fife is read into a KATE knowledge-base structure and this structure is then 
used m create T list of the flatfile objects for editing. A list of *e flatfile contents ,s 
shown in the list area and a tree diagram is automatically generated. The user can 
subsequently either select items for editing or add additional items to the flatfile under 
consideration. Whenever the user clicks on an item in either the list window or the 
tree window, an edit template is generated containing known information about the 
component. The user can then modify the item by typing in the template. Similarly, 
if the user wants to add items to a flatfile, he obtains a list of top-level classes and from 
a class obtains a list of all the known mid-level components for that class. Selecting 
one of these mid-level classes results in a blank template for the user to edit. ^ both 
editing situations, the editing templates popped up are constructed 
correspond to the specific class of object being edited. The information to do this 
derived from the TopLevelClass and MidLevelClass mentioned previously. 



Figure 4-3. The ECLSS Flatfile in the Flatfile Editor 
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ORIGINAL P'AQE IS 
OF POOR QUALITY 


At any time during the editing process the user can elect to save the edited file, switch 
to editing a different file, or use other KATE utilities such as the Schematic Viewer 
Frame Utility. Figure 4-3 illustrates an editing session. The names of the objects in the 
flatfile are listed on the left and a tree drawing is on the right. The menu bar can be 
seen just above these areas. 


4.4.3 STATUS. Much of the development effort this summer has been directed toward 
constructing a well-conceived foundation upon which the flatfile editor can be 
implemented. The major functions of the editor have been completed but many details 
remain. The automatic tree drawing capability of the FFE is in its infancy. There are 
probably a number of special cases in which the popup editing templates do not have 
exactly the correct editing fields displayed. It was not possible to incorporate the 
newly^ defined Synchronization Objects added to KATE this Summer. Also, the c ass 
of so-called TimeDependentObjects has not been dealt with. The Verify option on the 
menu bar is not implemented. 
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V 


REVIEW AND RECOMMENDATIONS 


5.1 CONCERNS 

For the most part the design illustrated in Figure 4-2 has proven to be a satisfactory 
approach S the implementation of the FFE. We believe this orgamzabon w,ll prove 
the easiest and most flexible editing organization to maintain as KATC evolves^ 
are however some significant problems which should be addressed if the FFE 

have long-term viability. 

First of all the scanning of the middle level header file (mid-level.hpp) is done in a 
very ad hoc manner. The structure of several header files was examined and cer am 
rules of thumb about their structure were adequate to implement ^ 

However there is no reason that a model builder constructing a middle level h 
Singly Stick with the same format. Any significant change to the 
structure of the middle level header files will necessitate updates to the kx gramma 
Ue For long Lm viability of the FFE an actual grammar should be - construct* sd fo 
the headeri.es and a genuine parser shouid be deve.operh The m.dd eve 
knowledge base is also being broken up into multiple files. "Hus will require som 
immediate minor restructuring of the FFE to accomodate this c ang . 

The second major concern is that the current prototype FFE does not do a good job 
with knowledge base constructs outside of its range of knowledge, o p , 

flatfile con taTJug Synchronization objects is read into the FFE and then written back 
to ^^^sSdLnlzation objects will not be written back to disk because as a 
^p FFe Ts concerned, they never existed in its realm of knowledge. A similar 
statement applies to "comment" fields within a flatfile which is read, processedan 
written back to disk. Currently we do not envision a simple so ution to j^bte 
since the FFE actually works solely with an internal representation of the flatfile and 
does not retain any other type of "image" of the file being e ite 

5.2 OTHER REMARKS 

A significant amount of work has been compieied vTry 

implementation of a knowledge-base editing environment The FFE ^ 

significant tenefifto KATE model builders. Except for the concerns mentioned above, 
we exoecl development to continue along the lines in which it is currently headed. 
Much of the remaining work should be in the nature of flushing out and completing 
modules already partially developed. With the exception of the icon drawing 
components, the FFE infrastructure is complete. 
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